20180608 Web Service QA Meeting June-2018 参加メモ
セッション
お題1「0からQAチームを立ち上げるまで」
お題2「キャリアプランとビジョンについて」
お題3「テストの生産性について」
sli.doで上位にあがったお題
お題1「0からQAチームを立ち上げるまで」
全体を把握したうえで、改善する
ステークホルダーが何を期待しているか把握する
QAをやるために改善しなければいけない範囲は広い 様々なところに関わっていく必要がある
キャッチコピーをつける 「痒い所に手が届く」
ロードマップなんてなかった
様々なところに関わっていくためには、経営層の理解を得ることが大事 ビジネスサイドに入りこむ
自分から、最初から、QAの役割を広げて定義してしまう
QAを必要としていない(偉い人がQAの価値をわかってない)組織には近づかない
まとめ：ステークホルダーの期待を理解しながら、貪欲に役割を広げていきましょう。
お題2「キャリアプランとビジョンについて」
答えは自分で作るもの そもそもがそういう業界なので
品質評価に関する新しいフレームワークやメソッドを考案するも良し
ISTQBが定義しているような様々なドメインに特化していくのも良し
まったく新しいロールを切り開いていくも良し
好奇心を持ち、遠慮なく人に会いに行って、機会を広げよう
新しい機会をものにしよう
自由にやっていい
自分が、その仕事を楽しくできるかどうかをひとつの判断基準にしても良い
テクニカルな解決方法を知っておくことは大事 これがないとキャリアがぼやける
マネジメントのスキルセットは、エンジニアのそれとは全然別のもの
スキルは学ぶことができる
話したくもない相手と話さなければいけない状況でどうするか、とか
マネジメントの役割をもらうときは、評価をする権限もセットでもらわないと危険
自分はプラス評価したのに本人にマイナス評価がつく、ということが発生しかねない
まとめ：つまりは、自分で考えよう。
お題3「テストの生産性について」
つまり、何を計測するか 計測した結果をどのように評価するか
従来のやり方では重すぎる
スピードを殺すようなやり方は歓迎されない
計測するよ派
プロダクト全体で見る(ライフサイクルも含めて)
お金(QAが入ったことで利益が上向いたということを数字で見せる)
障害の件数
自動テストの可用性
いろいろ(指標化できるものはどんどん見る)
シンプルなメトリクスを継続的に取ることで、変化を捕まえる
いろいろ計測したこともあったけど、腹落ち感のない指標は外した
(利益だけで評価すると、ドル箱プロダクトにみんな群がりたくなる)
計測しないよ派
生産性の計測にリソース振るくらいなら、新しいチャレンジをすることにそのリソースを使う
計測以外にやっていること
開発チームのやるテストの支援
まとめ：単純に障害件数を取る云々ではなく、よりビジネス上の価値に直結した数字を取るという声が多かったように感じます。ステークホルダー内で、腹落ち感のある指標にすることが大事だというのは納得。
sli.doで上位にあがったお題
開発が出来ない/知らないQAに未来は無いと思いますか？
未来ないよ派
できなくてもいいけど知らないのはダメかな
いいものかどうかを判断するための技術力は必要
未来あるよ派
できなくても知らなくても、他で才能を発揮できるなら全く問題ない
QAに求められるのは、人と人を繋ぐこと
(個人の感想)：QAの目的・目標がどこに置かれているか次第ではあるけれど、全体を広く俯瞰して、組織横断的に動ける人/組織横断的に頼られるような人が重宝されるのかな、という印象でした。Quesやテスト戦略を語る夕べで伺ったお話と繋がるのかなと思いますが、各ステークホルダーが求めている品質はそれぞれに違うので、それらを丁寧に拾って整理していくことが大事になるのかなと感じました。 全てのテストを開発者が自動化した場合でも、QAは必要だと思いますか
必要。
全部をコードで判断できるならいいけど、まあ現実的ではない
UXなど、自動化テストで判断できないものは残る
(ぼくが回答するなら)：必要だと思います。テスト自動化によって達成される成果、おそらくQAに求められる役割(成果)の一部。
チームビルディングの工夫
期待する役割を持たせる
「七人の侍」に当てはめたり、◯◯隊長といった名前をつけて、わかりやすくする
QAが提供する価値とはなんでしょうか？
いまを知る
(テストなんでしたいの？へのアンサーとして)
t_wadaさんがおっしゃるところの「体重計」
いまの品質状態を見える化する カメラや写真のイメージ
利益
会社の利益を最大化する
いい価値
いい価値を顧客に届けること
品質の向上
品質を作り込む
成功確率
成功確率を上げること
会社の偉い人たちにQAの価値を伝えるにはどうすればいいですか？
不具合を出した場合の損失(工数なども含む)を示し、それを回避できることに価値があると伝える
事業に影響があるような不具合を出す
一概に決めないほうがいい
判断材料を提供できるという価値 判断するのは経営者
(経営者がわかるような数字を出すべき、という意見もありました)
マネジメントの価値とは
なんとかすること
なんとかしてください
管理するだけがマネジメントではない
(個人の感想)：管理する人は、特にリーダーシップを発揮してほしい。リーダーシップもマネジメントも、メンバーを含めた全員が発揮することでチームが活性化していくと思っています。
(全体を通じて、個人の感想)：
もっと深いお話を伺いたい！という話題が多いイベントでした。キラキラした結果がどうしても目立つけど、そこに至るまでの苦労は想像を絶するものがあるのだろうなあ。。。
QAというロール自体が、やはり組織によってまちまちで、一括りに決めにかからない方が良いなという印象を受けました。世間の事例はあくまで事例で、自分たちがどうするかは自分たちで決めていきたいものです。それを自分がお伝えする側になれれば最高ですね。